This invention relates generally to computer software applications and more specifically to testing computer software applications.
A traditional client/server application is run in an enterprise that includes several client computers such as individual workstations. These workstations are connected, typically over a network to a central computer that is programmed with an application. The application program contains the business logic—or the instructions to perform the steps needed to make the application useful to the business that is using it. For example, the business logic for an application used by an insurance company would define such things as what types of insurance policies could be issued or the cost for each policy. The application program would also include transaction management software. The transaction management software would do such things as store and retrieve information from a database and pass the appropriate data back to the clients. Additionally, the application program would contain session control software. As multiple clients try to access the application, there must be control to ensure that these clients all operate properly. The session control software provides this control.
It should be noted that the user interface to the system is through the clients. A human user will input data through a client computer and call up data on the screen of the client computer. To test the application, the user interface has been the traditional point of connection to the system. Test systems that simulate the operation of the user can input data through the user interface and determine whether the appropriate results are achieved.
Traditionally, one of a few types of tests is performed. A functional test is a test in which an input is applied and an output is observed. If the expected output is not observed, it can be inferred that the program under test is not functioning correctly. Another type of testing is called load testing. Load testing is particularly important in a client/server application where there are many clients that could be operating simultaneously. As more clients operate, the response time slows down. In a load test, the test system stimulates more client/server interactions and measures the response time. Another type of test is called a regression test. The object of a regression test is to determine whether the performance of a piece of software has changed. Such a test might be used during software development to verify that the software was not adversely impacted by a change in the program. In a regression test, a known set of inputs is applied and the results measured and compared to values that were observed at a prior time (called the baseline) when the test was run.
A more recently developed architecture for an enterprise wide application is described as an N-tier enterprise model. This model also includes clients and a server. The server does the same functions as in a traditional application, however, the specific programs providing these functions are different. One difference is that the transaction management and session are not provided by the application program. Rather, they are provided by an application server, which is more generally described as a “container.” It will be appreciated that there are a finite number of functions that must be provided in order to do transaction management, such as store and retrieve data. Thus, there is no need to have application specific programs for each of these functions. The same is true for session control software. While the clients in each application might be doing different things, the need to coordinate the simultaneous use of all the clients is uniform across all applications. This function, too, is provided by the application server.
The business logic is the only function that is unique to the application. In the N-Tier enterprise model, the business logic is programmed as objects. One common programming language used for enterprise wide applications is a programming language capable of being interpreted by a network browser. One such programming language is often referred to as JAVA® (a registered trademark of Sun Microsystems). While any programming language could be used, in the description of the preferred embodiment the programming language JAVA® will be referred to. Objects in JAVA® that execute the business logic are often called “beans.” In the description of the preferred embodiment, the objects will be referred to as JAVAbeans™. However, it should be appreciated that objects created in other languages (also known as software components) might be used and could be tested in the same manner as described herein. Also, it is not strictly necessary that the business logic be implemented in an object-oriented language. The term “object” will be used in conjunction with the preferred embodiment. Also, the term Enterprise JAVAbean™, or EJB, will be used in conjunction with the preferred embodiment. However, it should be understood that the invention is not limited to testing enterprises that are programmed with an object-oriented language.
The application server is a commercially available program. There are approximately 5 widely used and commercially available application servers. Having the application server commercially available reduces the time it takes a programmer to develop an application. The application programmer can focus only on the objects needed to program the business logic. Testing should also focus on the objects that contain the business logic.
A further benefit that has resulted from the use of application servers is that the EJBs can be re-used in different applications, which will also run on the application servers. While not all applications will use any given EJB, it is possible that an EJB will perform a function used by similar applications. For example, many applications set up to take orders from consumers will have an EJB that performs the function of receiving and validating a credit card number. Thus, an application developer might write an EJB for this function and use that EJB for every order entry application developed.
We have identified several test challenges that result from the new architecture. First, the EJB has no user interface. As a result, the standard methods of testing through the user interface are not well suited to this type of testing because the user interface would have to be simulated before testing. Secondly, the EJB is often developed with the expectation that it will operate with any application server that might be available. In theory, each application server should respond to the software that is applied to it in the same way because each application server should meet a common specification. In practice, though, an EJB might perform differently on different application servers and might not work at all on some. It would be desirable to provide a service which tests software objects and thereby relieves the burden on a program developer to provide and support hardware and software for testing the software component or application.